Date: Wed, 20 Jul 94 04:30:07 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V94 #153 To: tcp-group-digest TCP-Group Digest Wed, 20 Jul 94 Volume 94 : Issue 153 Today's Topics: AX.25 behaviour problems with KA9Q unexpected text connections (2 msgs) Unsubscribe Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Tue, 19 Jul 1994 11:22:24 +0200 (BST) From: A.Cox@swansea.ac.uk (Alan Cox) Subject: AX.25 behaviour To: tcp-group@UCSD.EDU > If I have a process accepting AX.25 connections with the expectation > that imbedded protocols (tcp/ip, net/rom, etc) will be passed up to the > next protocol layer, but I don't have a text stream listener waiting on > the socket, what should I do when streamtext comes along? Reply with a > 'service not available' or 'no handler attached' message, and/or > disconnect? The Linux one deals with the problem by assuming you _have_ got something set up on the AX.25 stream connection and since its policy not implementation its up to the user process not the kernel to decide. At the moment you always get the PMS, but a program to recv() and send a 'Facility not available' is trivial. Alan ------------------------------ Date: Wed, 20 Jul 94 09:27:59 +0200 From: Robert HASSON Subject: problems with KA9Q To: tcp-group@ucsd.edu ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 4 I wrote to mike Chace who had advised me to contact your group for my little installing problems. So you can read my message in the attached file. Thanks in advance Robert Hasson ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: mail.txt X-Sun-Content-Lines: 11 Since I have some problems with installing KA9Q on my PC I think I should let you know what they are. Firstly I try to compile the modules with BCC and it answers me many errors relative to the which wasn't included in many files it was needed. But the biggest problem I have to deal with is the mismatching between and "stdio.h". Indeed, Karn had redefined the in/out modules but tries to use his own modules and the standard ones as there is an #include in the file mbuf.h which is included in the stdio.c which normally includes the "stdio.h" file. So more clearly the stdio.c includes both and "stdio.h". On top of that, the dofiles function is defined in the commands.h file, used in the stdio.c and the commands.h file is never included in the stdio.c nor in the stdio.h. You can know understand the kind of problems I have in trying to install this KA9Q. If you can see any solution to these problems please answer me. Sincerly yours, ------------------------------ Date: Tue, 19 Jul 1994 10:09:24 -0700 From: jackb@mdd.comm.mot.com (Jack Brindle) Subject: unexpected text connections To: brian@nothing.UCSD.EDU (Brian Kantor) >If I have a process accepting AX.25 connections with the expectation >that imbedded protocols (tcp/ip, net/rom, etc) will be passed up to the >next protocol layer, but I don't have a text stream listener waiting on >the socket, what should I do when streamtext comes along? Reply with a >'service not available' or 'no handler attached' message, and/or >disconnect? What's wrong with simply dropping the connection? The data needs to be routed on the basis of the AX.25 packet's PID (I don't like this either, but...), so if it's not for something you are looking for, simply drop the connection. If it is in UI mode, simply dropping the packet should be legitimate. >Where this happens is when a naive vanilla AX.25 user connects to a >port that's not normally configured to handle vanilla streamtext >connections. Just tossing the packet on the ground is uncool; it >leaves the user wondering whether his equipment has died or what. The question has to be what is worse, dropping the packet and leaving the user wondering, or filling the channel with rejection packets? Unnecessarily filling the channel may be even more uncool... Remember, closing the connection is one packet. Sending a rejection, then closing the connection is three (rejection notice, receive an ack, then DM the connection). >Or should an unattached streamtext socket become an echo server? >That is, the naive user would just get back everything he sends? Heavens, no. That is at least as bad as beaconing. Maybe when we get FDDI speeds on our RF channels... Jack Brindle ------------------------------------------------------------------------------ ham radio: wa4fib internet: jackb@mdd.comm.mot.com ------------------------------ Date: Wed, 20 Jul 1994 09:33:25 +0200 (BST) From: A.Cox@swansea.ac.uk (Alan Cox) Subject: unexpected text connections To: jackb@mdd.comm.mot.com (Jack Brindle) > What's wrong with simply dropping the connection? The data needs to > be routed on the basis of the AX.25 packet's PID (I don't like this > either, but...), so if it's not for something you are looking for, > simply drop the connection. If it is in UI mode, simply dropping > the packet should be legitimate. If your host is doing netrom and you get someone using straight AX.25 data down the same link (works in KA9Q...) then you'll keep throwing away loads of the netrom data each time it happens. Simply dropping the packets is very much cleaner. If someone wants they can write the AX.25 listener that echoes back 'Not active' or whatever.. Alan ------------------------------ Date: Wed, 20 Jul 94 01:15:35 EDT From: BenGarst@aol.com Subject: Unsubscribe To: TCP-Group@ucsd.edu Unsubscribe BenGarst@aol.com ------------------------------ End of TCP-Group Digest V94 #153 ******************************